1. Field of the Invention
This invention generally relates to the field of data validation and more specifically to asynchronous validation of data, in a client-server architecture.
2. Description of Related Art
As the use of the Internet and distributed networks increases, the exchange of information over long distances is increasing. Data validation over a distributed network, in particular, has enjoyed increasing popularity over the last few years. Users enter data into a graphical user interface (GUI) and the data is subsequently found to be valid or invalid by a server application. A common example of this is when a consumer enters personal and billing information into a series of web pages when purchasing a product over the Web. This process, however, can be long and time-consuming. Particularly, the user must often wait for validation of entered data before proceeding to enter more data. Thus, the user is often left to wait at the computer while validation processes. In addition, data validation sometimes occurs only after all data has been entered by the user. After a long wait, the user is often presented with a response indicating invalidity of entered data due to a minor error, such as entering date information in the wrong format (a two digit year code versus a four digit year code). This can be frustrating. The following describes in more detail the processes performed by the prior art.
FIG. 1 is a block diagram illustrating the overall system architecture of a typical distributed data validation system. A user 102 utilizes a client information processing system 104 (e.g., a computer) to enter data that is validated and saved by a server information processing system 108 (e.g., a web server) via a network 106 (e.g., the Internet). Typically, a client application such as a web browser that executes on client 104 provides data entry fields for entry of data by user 102. The entered data is then sent to a server application such as a Common Gateway Interface script that executes on server 108 for validation and storage of the entered data.
FIG. 2 is a flowchart depicting the overall operation and control flow of the data entry and validation processes of the prior art for multiple data entry field validation. The control flow of FIG. 2 begins with step 202 and flows directly to step 204. In steps 204 to 208, FIG. 2 shows that user 102 successively enters data into fields 1 through N provided by a client application executing on client 104. In step 210 the user 102 expresses a desire to save the data already entered. Alternatively, in step 210 the client application executing on the client 104 automatically asserts a command to save the data already entered. Consequently, the client application sends a message to a server application executing on server 108, wherein the message includes the data entered and a request to save the data entered. Note that steps 204 to 210 are executed by the user 102 and the client application on client 104.
Subsequently, server 108 receives the message sent by client 104 and proceeds to determine the validation status of the data already entered. This determination by server 108 is not timely. It would more constructive to receive feedback immediately after input of data in steps 204-208, instead of receiving feedback for all data entry fields all at once. This can be time-consuming and tedious.
If server 108 determines that the data entered is not valid, server 108 sends to client 104 a message indicating the invalidity of the entered data and control flows back to the first data entry position, in this example step 204. Thus, steps 204 to 212 are repeated over and over until the server 108 determines that the data entered is valid. Typically, when control flows back to step 204, the user 102 is presented with all data entry fields including information that indicates the reasons for invalidity of certain fields. This consumes resources and increases the time required to present a response to the user 102 that each data entry 1 through data entry N is valid
If server 108 determines that the data entered by user 102 is valid, the data entered is saved by server 108. Then, server 108 sends to client 104 a message indicating the validity of the entered data. Note that steps 212 to 214 are executed by the server application on server 108. In step 216, the control flow ceases. Although this prior art technique of validating all the data entry 1 through N after the data save command 210 is useful, it is time-consuming for the end user 102 to wait until all the data entries are entered to commence data validation. Accordingly, a need exists to overcome this time required for data validation.
Turning now to FIG. 3, shown is another flowchart depicting the overall operation and control flow of the data entry and validation processes of the prior art for individual data field validation. The control flow of FIG. 3 begins with step 302 and flows directly to step 304. In step 304, FIG. 3 shows that user 102 enters data into a data entry field provided by a client application executing on client 104. Next, in step 306, the client application sends a message to a server application executing on server 108, wherein the message includes the data entered. The server 108 receives the message sent by client 104 and proceeds to determine the validation status of the data entered. This determination by server 108 can require a considerable amount of time to accomplish. During this time, the user 102 must wait for a response from server 108 without being able to enter any additional data into other data entry fields. Again, this can be time-consuming and tedious.
If server 108 determines that the data entered is not valid, server 108 sends to client 104 a message indicating the invalidity of the entered data and the user 102 is given another opportunity to enter data into that data field, in this example step 304. Thus, steps 304 to 306 are repeated over and over until the server 108 determines that the data entered is valid. The sequence of steps represented by steps 304 and 306 is repeated for each data entry field 1 through N—steps 308 to 314. Thus, the total time consumed for the process is the sum of each determining step, i.e., the sum of each determining step for each data entry field 1 through N—steps 306, 310 and 314. This is disadvantageous as it increases the time necessary for a user 102 to obtain validation of entered data. It should be noted that the data entry fields 1 through N are not necessarily visited by the user 102 in the order of their designation.
In step 316, the user 102 indicates a desire to save the data already entered and the client application sends a message to the server application executing on server 108, wherein the message includes the data entered and a request to save the data entered. Then, the data entered by user 102 is saved by server 108. Note that steps 304, 308, 312, and 316 are executed by the user 102 and the client application on client 104. Also note that steps 306, 310, 312, and 318 are executed by the server application and server 108. Although this prior art technique of validating each data entry field sequentially is useful, it is very time-consuming to force the user 102 to wait for each field to validate prior to proceeding to the next field.
Therefore a need exists to overcome the problems with the prior art as discussed above, and particularly for a way to more efficiently validate data entered into a field within a user interface.